Amazon EventBridgeを用いて、複数アカウントのAWS IAM Access Analyzerの検知を1つのアカウントに集約してみた

Amazon EventBridgeを用いて、複数アカウントのAWS IAM Access Analyzerの検知を1つのアカウントに集約してみた

AWS Organizationsを使えばIAM Access Analyzerを集約できますが、諸事情でAWS Organizationsを使用していない場合もあります。その際にはAmazon EventBridgeなどを用いて集約を実装する必要があります。
Clock Icon2024.01.11

AWS IAM Access Analyzerをまとめて管理したい

おのやんです。

みなさん、複数アカウントのAWS IAM Access Analyzer(以下、IAM Access Analyzer)を1つのアカウントに集約したくないですか?私は集約したいです。

AWS Security Hub(以下、Security Hub)やAmazon GuardDuty(以下、GuardDuty)などのセキュリティサービスでは、複数のメンバーアカウントを管理者アカウントで管理できる機能があります。具体的には、メンバーアカウントに対して、管理者アカウントへ「招待」ができます。

一方で、他のセキュリティサービスのひとつであるIAM Access Analyzerは、デフォルトで集約する機能を持ちません。AWS Organizationsを使えば、IAM Access Analyzerを集約して管理できますが、諸事情でAWS Organizationsを使用していない場合もあります。その際には、Amazon EventBridge(以下、EventBridge)などを用いてIAM Access Analyzer集約を実装する必要があります。

ということで今回はEventBridgeを用いて、メンバーアカウントのIAM Access Analyzerを管理者アカウントに集約してみたいと思います。

構成

全体の構成は以下の図のようになります。

メンバーアカウントでは、IAM Access Analyzerが有効になっています。この検知を、EventBridgeのデフォルトバス(以下、EventBridgeバス)が受け取ります。このデフォルトパスのEventBridgeルールには、管理者アカウント側のEventBridgeバスがターゲットとして指定されています。こうすることで、管理者アカウント側のEventBridgeバスにIAM Access Analyzerの検知が送信されます。管理者アカウント側のEventBridgeルールでは、SNSトピックがターゲットとして設定されています。こうしてEventBridgeを数珠繋ぎにすることで、IAM Access Analyzerの検知をメールで送信できます。

実装してみた

それでは、IAM Access Analyzer集約を実際に実装してみましょう。なお、メンバーアカウントでIAM Access Analyzerは有効化されているものとします。

SNSの設定

まずは、管理者アカウント側でSNSの設定を行います。

まずは、SNSトピックから設定します。今回はtest-iam-access-analyzer-notificationという名前をつけました。トピックのタイプはスタンダードで進めます。

トピックの作成が完了したら、続いてSNSのサブスクリプションの設定も行いましょう。トピック詳細画面のサブスクリプションタブから、新規のサブスクリプションを作成できます。

サブスクリプションの設定では、エンドポイントのタイプとして「Eメール」を選択します。エンドポイントには、通知したいメールアドレスを入力しておきます。これらを設定できたら、サブスクリプションを作成します。

作成が完了したら、エンドポイントとして登録したメールの受信フォルダをチェックします。AWS Notification - Subscription Confirmationというタイトルのメールが届いているので、こちらを開いてみます。すると、Confirm Subscriptionというリンクが書かれたメール本文が確認できます。このConfirm Subscriptionリンクをクリックします。

ブラウザの新規タブがこのように開いたら、サブスクリプションの設定は完了です。

トピック詳細画面を開いてみると、このようにステータスが「確認済み」となっていることが確認できます。

管理アカウント側EventBridgeの設定

続いて、EventBridgeの設定を行います。

まず、管理アカウント側EventBridgeのルール画面から、ルールを作成します。

ルールの詳細定義の画面では、適当な名前をつけておきます。今回はtest-iam-access-analyzer-ruleという名前にしました。イベントバスは「デフォルト」、ルールタイプは「イベントパターンを持つルール」で設定します。

イベントパターンの構築画面では、イベントソースとして「その他」を選択します。

メソッドは「カスタムパターン (JSONエディタ)」を選択します。また、イベントパターンとして、以下のJSONを設定します。

{
  "source": [
    "aws.access-analyzer"
  ],
  "detail-type": [
    "Access Analyzer Finding"
  ],
  "detail": {
    "isDeleted": [
      false
    ]
  }
}

EventBridgeルールのターゲットでは、先ほど作成したSNSトピック(test-iam-access-analyzer-notification)を選択します。

EventBridgeルールが正常に作成できれば、このようにルール一覧画面にtest-iam-access-analyzer-ruleが追加されます。

次に、イベントバスのIAMポリシーを設定します。まず、EventBridgeバスの画面に移動します。今回設定しているのはdefaultバスですので、defaultバスの設定に移動します。

この「許可」タブのリソースベースのポリシーを編集し、以下のポリシーに置き換えます。

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowAccountToPutEvents",
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::{メンバーアカウントID}:root"
    },
    "Action": "events:PutEvents",
    "Resource": "arn:aws:events:ap-northeast-1:{管理アカウントID}:event-bus/default"
  }]
}

最後に、管理アカウントのデフォルトバスのARNをコピーしてメモしておきます。これらが終われば、管理アカウント側のEventBridgeの設定は完了です。

メンバーアカウント側EventBridgeの設定

メンバーアカウント側EventBridgeの設定項目は、基本的には管理アカウント側EventBridgeと同じです。ただし、メンバーアカウント側EventBridgeルールのターゲットは、さきほどのSNSトピックではなく、管理者アカウントのデフォルトバスになります。

そのため、ターゲット設定画面では、ターゲットタイプとして「EventBridgeイベントバス」、「別のアカウントまたはリージョンのイベントバス」を選択します。また、ターゲットとしてイベントバスの指定する際には、さきほどメモした管理者アカウントのデフォルトバスARNを入力します。

ちなみに、ここでは管理者アカウントのデフォルトバスARNから自動で実行ロールが作成されます。このロールの許可は、JSONでは次のようになります。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "events:PutEvents"
            ],
            "Resource": [
                "arn:aws:events:ap-northeast-1:{管理アカウントID}:event-bus/default"
            ]
        }
    ]
}

以上が、メンバーアカウント側EventBridgeの設定になります。

検証

それでは、実際にIAMAccess Analyzerが集約されているか確認してみましょう。

今回はメンバーアカウント側のS3バケットのバケットポリシーを編集して、クロスアカウントアクセスを一時的に許可してみます。

S3バケットのバケットポリシー編集画面に移動し、以下のポリシーに設定します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": "s3:*",
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::{クロスアカウントアクセスを許可するS3バケットのARN}",
      "Principal": {
        "AWS": [
          "{別アカウントのID}"
        ]
      }
    }
  ]
}

数分後に、このようなメールが届いていたら、正しく設定されています。モザイクをかけているため分かりにくいですが、メールの本文はIAM Access Analyzder検知のJSONになっています。

メンバーアカウントで発生したIAM Access analyzerの検知が管理者アカウントに正常に送信され、そこからメールが送信されていることがわかります。

さいごに

今回紹介した設定は、EventBridgeのルールなどを変更すれば他の集約設定にも応用可能です。マルチアカウント集約の際にOrganization以外の方法で設定する場合は、ぜひ参考にしてみて下さい。では!

参考

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.